Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-123

Text File | 1995-12-31 | 89.4 KB | 2,359 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 24 Nov 95       Volume 3 : Issue 123

Today's Topics:

        Backgrounding during printing?
        Books on programming in assembly?
        Getting PC Exchange file names
        Is this code necessary?
        Memory move-purge and HLock Question???
        Multiple frame buffers and page flipping
        Photoshop "CLUT" into 'clut'
        Question: Best format for saving region data?
        Serial baud rates > 57.6KBaud?
        [Q] Macsbug ATB in PPC apps?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From Spencer W Thomas <[e-mail]>
Subject: Backgrounding during printing?
Date: 8 Nov 1995 07:43:25 GMT
Organization: University of Michigan

This seems such an obvious question, I'm baffled that I haven't been able to
find the answer in any of the Apple docs.  If I need to RTFM, just tell me
which FM and I'll do it!

I'm developing an app that I would really like to be able to background while
printing.  Since the print driver puts it's window frontmost, and it's a modal
dialog, I can't.  But I figure there's GOT to be some trick I'm missing.

What is it?

Thanks.
--
=Spencer W. Thomas      |  SILS, 312 W. Engin.
   Digital Libraries    |  Univ of Michigan, Ann Arbor, MI 48109
[e-mail]       |  313-764-5099, FAX [phone]


+++++++++++++++++++++++++++

>From Duane Murphy <[e-mail]>
Date: Wed, 8 Nov 1995 16:09:20 GMT
Organization: Bear River Associates

In article <47pn2t$[e-mail]> Spencer W Thomas,
[e-mail] writes:
>I'm developing an app that I would really like to be able to background while
>printing.  Since the print driver puts it's window frontmost, and it's a modal
>dialog, I can't.  But I figure there's GOT to be some trick I'm missing.
>
Spencer,
No trick; no technique. The answer is simple. You cant do it ;-)

It turns out that the printing manager is (horribly) non-reentrant. So,
you cant print in the background. It must be the only thing operating.

Please, someone correct me if I'm wrong.

...Duane

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Thu, 9 Nov 1995 17:20:03 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, Duane Murphy
<[e-mail]> wrote:

> In article <47pn2t$[e-mail]> Spencer W Thomas,
> [e-mail] writes:
> >I'm developing an app that I would really like to be able to background while
> >printing.  Since the print driver puts it's window frontmost, and it's
a modal
> >dialog, I can't.  But I figure there's GOT to be some trick I'm missing.
> >
> Spencer,
> No trick; no technique. The answer is simple. You cant do it ;-)
>
> It turns out that the printing manager is (horribly) non-reentrant. So,
> you cant print in the background. It must be the only thing operating.
>
> Please, someone correct me if I'm wrong.

You're right, and you're wrong.  :-)

It's true that the old style PrXXX API doesn't allow this.

However, if you use the GX printing API, the spooling dialog is
moveable modal, and the user can swap to the background.

The GX API is a one for one swap with the existing API, and quite
easy to add to most applications conditionally.  SimpleText does
it this way, and Dave Hersey had an article in _develop_ on how to
add this to your application.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (David Opstad)
Date: 10 Nov 1995 08:51:33 -0800
Organization: Apple Computer Inc, Cupertino, CA

In article <dowdy-0911950920030001@17.202.32.83>,
Tom Dowdy <[e-mail]> wrote:
>
>The GX API is a one for one swap with the existing API, and quite
>easy to add to most applications conditionally.  SimpleText does
>it this way, and Dave Hersey had an article in _develop_ on how to
>add this to your application.

A Web version of this article may be found at this URL:

http://support.info.apple.com/gx/PRNT/Hersey.html

Dave Opstad
GX Line Layout Weenie

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: Wed, 08 Nov 1995 19:31:00 -0800
Organization: Aladdin Systems

In article <47pn2t$[e-mail]>, Spencer W Thomas
<[e-mail]> wrote:
>I'm developing an app that I would really like to be able to background while
>printing.  Since the print driver puts it's window frontmost, and it's a modal
>dialog, I can't.  But I figure there's GOT to be some trick I'm missing.
>
The short answer is "You can't".
While you can do some weirdness with patching NewWindow and changing the
window type (or other bad things), it's not a good idea.

The basic problem is that the print manager is not re-entrant. If you are
printing in the background, and another application brings up a print
dialog, _somebody_ will crash. :-(

Of course, this is easy in QuickDraw GX.

-- Marshall

--
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety." -- Benjamin Franklin
 _Historical Review of Pennsylvania_, 1759

---------------------------

>From [e-mail] (James R Cantrell)
Subject: Books on programming in assembly?
Date: 5 Nov 1995 19:17:50 -0800
Organization: CRL Dialup Internet Access        [phone]  [Login: guest]

   Anyone know any good books that go over how to program in assembly
language for the PPC?


Thanks,
Joshua Cantrell
[e-mail]
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Frank Henriquez)
Date: Mon, 06 Nov 1995 12:52:09 -0800
Organization: UCLA Astronomy Department

In article <47juou$[e-mail]>, [e-mail] (James R Cantrell) wrote:

>   Anyone know any good books that go over how to program in assembly
>language for the PPC?
>
>

Joshua:
  There's "Optimizing PowerPC Code" by Gary Kacmarcik (Addison Wesley ISBN
0-201-40839-2). It's not Mac specific, but it is a detailed book on the
PPC assembly language. It's around $40.

I saw another PPC assembly book at a bookstore recently, but I forgot the
title. It looked good, too.

Frank

--
Frank Henriquez                  UCLA Astronomy Department
[e-mail]        -or-       [e-mail]

---------------------------

>From [e-mail] (Piran Montford)
Subject: Getting PC Exchange file names
Date: Sat, 28 Oct 1995 19:50:37 +0100
Organization: Auk Word Computing

Simple question:

how do I guess/calculate/find the name of Mac file when it's copied to a
PC Disk using PC Exchange, or mounted using AppleShare client for Windows.

This information must be available, because if you do get info on a file
name, and click on the file's name in the info window, it shows the PC
version. However, I can't access this information.

I've worked out a system to convert file names to what they'll appear as,
but if two files have similar names then it is determind by which is first
in the catalogue, not alphabetic order. And I only seem to be able to pull
out file names in alphabetical order.

Any suggestions?

atdhvaannkcse, Piran.
--
"I think ahead of you, I think instead of you." - Tricky
Piran at home: mailto:[e-mail],  http://pobox.com/~piran
Piran at work: mailto:[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 3 Nov 1995 00:53:22 -0500
Organization: America Online, Inc. (1-800-827-6364)

Piran Montford wrote:

>how do I guess/calculate/find the name of Mac file when it's
>copied to a PC Disk using PC Exchange, or mounted using
>AppleShare client for Windows.

You need to use the little-known call PBGetXCatInfo (note the "X"). The
call is documented in the "Guide to the File System Manager" so that
foreign file systems can implement it like AppleShare and the DOS file
system in PC Exchange. If you have File Sharing running or a DOS disk
mounted with PC Exchange, the "short name" returned by PBGetXCatInfo is
what the Finder displays when you click on the filename shown in the "Get
Info..." Finder dialog.

Apple II fans: Note that you also get the ProDOS file/aux type from this
call :-)

I searched around on my hard disk for a snippet that uses PBGetXCatInfo
and found the code that I've pasted below. (This'll probably piss off the
Copland File System team since they have no plans to implement this call.)

- Jim Luther, former keeper of obscure File Manager knowledge

/*************************************************************************
*/

/* A few things that aren't in the interface files */

struct XCInfoPBRec {
  QElemPtr  qLink;
  short     qType;
  short     ioTrap;
  Ptr       ioCmdAddr;
  ProcPtr   ioCompletion;   /* --> A pointer to a completion routine */
  OSErr     ioResult;       /* --> The result code of the function */
  StringPtr ioNamePtr;      /* --> Pointer to pathname to object */
  short     ioVRefNum;      /* --> A volume specification */
  long      filler1;
  StringPtr ioShortNamePtr; /* <-> A pointer to the short name string
                                   buffer - required! */
  short     filler2;
  short     ioPDType;       /* <-- The ProDOS file type */
  long      ioPDAuxType;    /* <-- The ProDOS aux type */
  long      filler[2];
  long      ioDirID;        /* --> A directory ID */
};
typedef struct XCInfoPBRec XCInfoPBRec;
typedef XCInfoPBRec *XCInfoPBPtr;

/*************************************************************************
****/

#pragma parameter __D0 PBGetXCatInfoSync(__A0)
pascal OSErr PBGetXCatInfoSync(XCInfoPBPtr paramBlock)
 = {0x703A,0xA260};
#pragma parameter __D0 PBGetXCatInfoAsync(__A0)
pascal OSErr PBGetXCatInfoAsync(XCInfoPBPtr paramBlock)
 = {0x703A,0xA660};

/*************************************************************************
****/

pascal  OSErr  GetXCatInfo(short vRefNum,
                           long dirID,
                           StringPtr name,
                           StringPtr shortName,
                           short *ProDOSFileType,
                           long *ProDOSAuxType);
/* Use GetXCatInfo to retrieve the MS-DOS short name and ProDOS
   file/aux type of the file or directory specified.

   vRefNum         input:  Volume specification.
   dirID           input:  Directory ID.
   name            input:  Pointer to object name, or nil when dirID
                           specifies a directory that's the object.
   shortName       input:  Points to a buffer (minimum String[12]) where
the
                           MS-DOS short name is to be returned. This
                           *cannot* be nil.
   ProDOSFileType output:  The ProDOS file type
   ProDOSAuxType  output:  The ProDOS aux type
*/

pascal  OSErr  GetXCatInfo(short vRefNum,
                           long dirID,
                           StringPtr name,
                           StringPtr shortName,
                           short *ProDOSFileType,
                           long *ProDOSAuxType)
{
  XCInfoPBRec pb;
  OSErr result;

  /* The system always returns the short name, so the shortName buffer is
     required */
  if (shortName != nil)
  {
    pb.ioVRefNum = vRefNum;
    pb.ioDirID = dirID;
    pb.ioNamePtr = name;
    pb.ioShortNamePtr = shortName;
    result = PBGetXCatInfoSync(&pb);
    *ProDOSFileType = pb.ioPDType;
    *ProDOSAuxType = pb.ioPDAuxType;
  }
  else
    result = paramErr;  /* no short name buffer */

  return (result);
}

/*************************************************************************
*/

pascal  OSErr  FSpGetXCatInfo(const FSSpec *spec,
                              StringPtr shortName,
                              short *ProDOSFileType,
                              long *ProDOSAuxType);
/* Use FSpGetXCatInfo to retrieve the MS-DOS short name and ProDOS
   file/aux type of the file or directory specified.

   spec            input:  An FSSpec record specifying the object.
   shortName       input:  Points to a buffer (minimum String[12]) where
the
                           MS-DOS short name is to be returned. This
                           *cannot* be nil.
   ProDOSFileType output:  The ProDOS file type
   ProDOSAuxType  output:  The ProDOS aux type
*/

pascal  OSErr  FSpGetXCatInfo(const FSSpec *spec,
                              StringPtr shortName,
                              short *ProDOSFileType,
                              long *ProDOSAuxType)
{
  return (GetXCatInfo(spec->vRefNum, spec->parID, (StringPtr)spec->name,
                      shortName, ProDOSFileType, ProDOSAuxType));
}

/*************************************************************************
*/

+++++++++++++++++++++++++++

>From [e-mail] (Sean McBride)
Date: Fri, 10 Nov 1995 17:35:58 -0500
Organization: Communications Accessibles Montreal, Quebec Canada

In article <47caoi$[e-mail]>, [e-mail] (Jump
Long) wrote:

>You need to use the little-known call PBGetXCatInfo (note the "X"). The
>call is documented in the "Guide to the File System Manager" so that
>foreign file systems can implement it like AppleShare and the DOS file
>system in PC Exchange. If you have File Sharing running or a DOS disk
>mounted with PC Exchange, the "short name" returned by PBGetXCatInfo is
>what the Finder displays when you click on the filename shown in the "Get
>Info..." Finder dialog.
>
>Apple II fans: Note that you also get the ProDOS file/aux type from this
>call :-)
>
>I searched around on my hard disk for a snippet that uses PBGetXCatInfo
>and found the code that I've pasted below. (This'll probably piss off the
>Copland File System team since they have no plans to implement this call.)

So the File System Manager won't be available in Copland?  I guess that'd
mean that PC Exchange won't work, at least not the current version.

I really hope that Copland will be able to read and write MS-DOS and
ProDOS disks... I expect reading DOS disks will be available, but I fear
they won't bother with ProDOS...

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  H H      |                   |                                       |
  | |      | Sean McBride      |                                       |
H-C-C-O-H  | [e-mail]   |   "Total destructive interference"    |
  | |      | Montreal, Canada  |   "For Unlawful Carnal Knowledge"     |
  H H      |                   |                                       |
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---------------------------

>From [e-mail] (Chuck Stricklin)
Subject: Is this code necessary?
Date: Sat, 4 Nov 1995 00:15:03 GMT
Organization: Mississippi State University

I've been looking over Apple's Pascal Sample 3.0B10 code and found this
initialization code which I think may be outdated. Can anyone give me a
reason why I should or shouldn't dump this code?

kMinHeap = 60 * 1024;
kMinSpace = 24 * 1024;
kPrefSize = 200;
kMinSize = 180;

for count := 1 to 3 do
 ignoreResult := EventAvail(everyEvent, event);

if ORD(GetApplLimit) - ORD(ApplicZone) < kMinHeap then
 AlertUser(rNoMemoryForApp);

PurgeSpace(total, contig);
if total < kMinSpace then
 AlertUser(rNoMemoryForApp);

--
"Giving money and power to government is like giving
liquor and car keys and teenage boys." - P.J. O'Rourke

+++++++++++++++++++++++++++

>From [e-mail] (Nathan Tennies)
Date: Sat, 04 Nov 1995 17:42:40 -0400
Organization: Bootstrap Enterprises Inc

In article <[e-mail]>,
[e-mail] (Chuck Stricklin) wrote:

> I've been looking over Apple's Pascal Sample 3.0B10 code and found this
> initialization code which I think may be outdated. Can anyone give me a
> reason why I should or shouldn't dump this code?
>
> kMinHeap = 60 * 1024;
> kMinSpace = 24 * 1024;
> kPrefSize = 200;
> kMinSize = 180;
>
> for count := 1 to 3 do
>  ignoreResult := EventAvail(everyEvent, event);
>
> if ORD(GetApplLimit) - ORD(ApplicZone) < kMinHeap then
>  AlertUser(rNoMemoryForApp);
>
> PurgeSpace(total, contig);
> if total < kMinSpace then
>  AlertUser(rNoMemoryForApp);

Well, I don't know what the history of the EventAvail loop is, or exactly
what it does.  All I know is that two of my apps had the problem of the
splash window appearing _behind_ all the other open windows in other
programs untl I put this loop in.  Then everything worked fine.  I'm
guessing that maybe the Finder doesn't bring the app's window layer to the
front until it senses that it is receiving events.  You got me.

The first if/then/alert phrase is used to guarantee that your app has the
minimum amount of memory it needs to operate successfully.  Your first
line of defence against this are the MinSize fields in SIZE resources,
which sets the minimum amount of memory the OS allocates to your app when
launched.  However, since the user can override this amount, this code
guarantees that your app won't run unless it has enough RAM.

Also, this code is checking for a different value than the MinSize field
of the SIZE resource does.  I think the MinSize field may be spcifying the
minimum size of the entire chunk of RAM allocated to an app, which
includes both the stack and heap.  However, this code is checking
specifically for a minimum size of the heap alone.  The only reason I can
think of why this is done this way is in case different systems allocate
different amounts of memory for the stack, which will eat into the minimum
amount available for the heap (can anyone verify this?).  Finally, make
sure you're using those newfangled doohickey "accessor" functions (or
whatever they're called) in place of accessing the low-level global
variables directly.

The second if/then/alert phrase is used to gurantee a similar quality; the
amount of heap space availablek, including purgeable blocks, after the
program is loaded and running.  This will be less than the total block
size measured in the first if/then/alert phrase, since any unpurgeable
code and automatically loaded resources will be use up some of that
memory.  This could be useful, I'd guess, in the case where you have a FAT
version of your app in which the PowerPC code will all be loaded in
one-fell swoop (and will be bigger at that) whereas the 68K code will
still be loaded piecemeal (and will be more compact).  In either case,
you'd want to guarantee that you had X amount of memory available for the
program to run correctly.

Frankly, I think I'd tend to use just the second of these if/then/alert
phrases, since it more accurately measures the quantity that is probably
of greatest interest.  I'd probably preceed this phrase with a call to
MaxApplZone.

If anyone can think of a good reason to include _both_ of these
if/then/alert phrases, I'd like to know.

Nathan Tennies
Bootstrap Enterprises Inc

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Mon, 6 Nov 1995 13:58:38 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>,
[e-mail] (Nathan Tennies) wrote:
>
======big snip======
>
> Also, this code is checking for a different value than the MinSize field
> of the SIZE resource does.  I think the MinSize field may be spcifying the
> minimum size of the entire chunk of RAM allocated to an app, which
> includes both the stack and heap.  However, this code is checking
> specifically for a minimum size of the heap alone.  The only reason I can
> think of why this is done this way is in case different systems allocate
> different amounts of memory for the stack, which will eat

This rings a bell - I'm pretty sure that the default stack/heap split
on the MacPlus is different to, say, a Mac II etc.  I have a note
on this at home, so I'll check later.  I know that to get around this
in one of my own apps. I explicitly adjusted the heap limit to get the
required amount of stack space.

Dave Stone

+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Wed, 08 Nov 1995 17:53:47 -0900
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (Nathan Tennies) wrote:

>In article <[e-mail]>,
>[e-mail] (Chuck Stricklin) wrote:
>
>> I've been looking over Apple's Pascal Sample 3.0B10 code and found this
>> initialization code which I think may be outdated. Can anyone give me a
[code omitted]

>Well, I don't know what the history of the EventAvail loop is, or exactly
...
>guessing that maybe the Finder doesn't bring the app's window layer to the
>front until it senses that it is receiving events.  You got me.

That's right.

>specifically for a minimum size of the heap alone.  The only reason I can
>think of why this is done this way is in case different systems allocate
>different amounts of memory for the stack, which will eat into the minimum

That's right.  The minimum heap is larger on machine with Color Quickdraw,
for example.

>Frankly, I think I'd tend to use just the second of these if/then/alert
>phrases, since it more accurately measures the quantity that is probably
>of greatest interest.  I'd probably preceed this phrase with a call to
>MaxApplZone.

I agree.  There's probably no good reason for both, provided kMinSpace is
made large enough.

(Consider the situations in which the first check would fail but the
second succeed.   That would mean that the heap size was too small, but
the amount of free space was OK.)

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

---------------------------

>From "Paul N. Taylor" <[e-mail]>
Subject: Memory move-purge and HLock Question???
Date: Wed, 8 Nov 1995 15:19:02 +0000
Organization: University of Hertfordshire

Hi all,
        I would like to know when to use 'purge' in resource definitions
(i.e: in resedit) and when not to use it. Also, the recommended use for
HLock/HUnlock. Does it have to be used with all routines quoted in IM???

The reason for this request for info is because I keep getting random crashes
of some software of mine (Macbugs error: Spurious Interrupt....???).

Could this be a memory purge on something currently in use by the
processor???

Needless to say, help! Someones experiences in this area would help as
I'm a bit new to the finer points of locking out changes and purging.

Thanks in advance, regards,

P.T.

[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Devon Hubbard)
Date: Wed, 08 Nov 1995 14:39:08 -0800
Organization: Apple Computer

In article <[e-mail]>,
"Paul N. Taylor" <[e-mail]> wrote:

> I would like to know when to use 'purge' in resource definitions
> (i.e: in resedit) and when not to use it. Also, the recommended use for
> HLock/HUnlock. Does it have to be used with all routines quoted in IM???

Asking when to use and not use 'purged' flags on a resource is really a
loaded question.  It all depends on your application, the size of it's
heap, and what you have going on in that heap.  If you have some dialog,
pict, string, etc. that only comes up maybe once in the entire user
experience then make it's contents purgeable so when the user doesn't have
that dialog up the memory it uses can be purged and available to something
else.  Back when 8, 16, and 24 mb Macs weren't so common, purgeable heap
blocks was more of an issue.  These days it's not such a big deal and
[sadly] a lot of developers just up their heap size instead of finding the
cause of some heap related problem.  If you have something that is
referenced a lot in your application, don't mark it purgeable because
you'll just end up reading it back again on the next reference.  But if
it's something you only use one or twice (or occassionally), then mark it
purgeable so it'll go away if needed.  BE VERY CAREFUL with your
references to handles that are marked purgeable.  Check (i.e. 'if (!*h)' )
to make sure the data is there before using it, otherwise LoadResource()
the handle again if it's been purged or you're going to run into trouble.
Depending on what the resource was, you could not see garbage in a window
(strings, picts, icons, etc.) or you could crash if it's data or something
where it's absence is lethal to your app.

> The reason for this request for info is because I keep getting random crashes
> of some software of mine (Macbugs error: Spurious Interrupt....???).
> Could this be a memory purge on something currently in use by the
> processor???

It definetely could be.  It could unfortunately be quite a lot of things.
Is the error reproducible?  If so, then there's 90% of the work right
there.  Creating a reproducible case is very important because you can
then walk backwards to the cause.  Obviously that can take 10 minutes or
10 hours depending on what the heck is going on.

I'd really like to suggest you try a tool called QC(tm) from Onyx
Technology. We could write back and forth for a long time slowly isolating
the cause of your problems, or you can use QC which was specifically
designed to help you track down memory related problems like this.  See
<http://www.std.com/onyxtech/> for details.  There's a fully functional
demo available so you really can't lose for trying because it's free.  The
demo, that is.

I'd be happy to try and help you figure out what's happening in your app,
as I'm sure many others here on csmp would be.

Cheers,
dEVoN

---------------------------

>From [e-mail] (Ian McLean)
Subject: Multiple frame buffers and page flipping
Date: 3 Nov 1995 05:37:41 GMT
Organization: Internet Communications Group

Okay, now that I've flamed CodeWarrior a bit (aah, felt good; relieved some
stress; all in all I think it's a pretty good development environment
though) and gotten some good advice about alternative compilers, I've got a
more technical topic: high performance blitting on the Mac.

Is it possible?  Right now I'm working on a side scrolling game that, every
frame, renders a span buffer into an off-screen bitmap, then CopyBits() to
the screen.  I assume that CopyBits() waits for a vertical retrace before
blitting, as I don't seem to have any tearing problems.  So, this method
works, but it seems terribly inefficient.

I would like to implement some double or, preferably, triple buffering
scheme.  This would mean I'd render the span buffer right into video memory,
and then make that the currently visible frame by programming a video chip
register, eliminating the overhead of transfering the bitmap to the video
card in the CopyBits() call.  Is this possible?  I have no clue how the
Macintosh video architecture works.  Is it possible to change the video
resolution and bit depth, take control of the entire video display, and
access it directly?  Oh, this games runs in 512x384 256-color mode, by the
way (it'll run in 640x480 with unused borders around the gameplay area).

The Windows version of this product will be doing things with a double-
buffer, rendering directly to video memory using Windows 95 DirectDraw, and
I'd love for the Mac to be able to do something similar.  Anyone have any
suggestions or feel like giving me a quick tutorial on Mac video modes?

                                Thanks,
                                  Ian McLean
                                  Cyberflix, Inc.


+++++++++++++++++++++++++++

>From [e-mail] (Gavin Kistner)
Date: Sat, 04 Nov 1995 17:40:39 -0500
Organization: Image Refinery Productions, Inc.

In article <47c9r5$[e-mail]>, [e-mail] (Ian McLean) wrote:
[snip]
>I would like to implement some double or, preferably, triple buffering
>scheme.  This would mean I'd render the span buffer right into video memory,
>and then make that the currently visible frame by programming a video chip
>register, eliminating the overhead of transfering the bitmap to the video
[snip]

Marathon (the original, and I assume 2) uses this, but...
I believe that this was possible on the Quadra 630 (oslt) and is not
possible on any other mac.  Someone PLEASE correct me if I'm wrong here.

- Gavin
___________________________________________________________
Gavin Kistner, aka RabYak, aka !Bob          [phone]
<-> Graphics Designer, Image Refinery Productions, Inc. <->
[e-mail]       ftp/finger to phrogz.dorm.duke.edu

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Sat, 04 Nov 1995 22:59:01 -0800
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <47c9r5$[e-mail]>, [e-mail] (Ian McLean) wrote:

> Is it possible?  Right now I'm working on a side scrolling game that, every
> frame, renders a span buffer into an off-screen bitmap, then CopyBits() to
> the screen.  I assume that CopyBits() waits for a vertical retrace before
> blitting, as I don't seem to have any tearing problems.  So, this method
> works, but it seems terribly inefficient.

CopyBits does not wait for the vertical blank -- you can get tearing with
it. If you want to sync with the VBL it is somewhat tricky. Not hard, but
there are a lot of small details. And it's a b***h to debug.

> I would like to implement some double or, preferably, triple buffering
> scheme.  This would mean I'd render the span buffer right into video memory,
> and then make that the currently visible frame by programming a video chip
> register, eliminating the overhead of transfering the bitmap to the video
> card in the CopyBits() call.  Is this possible?  I have no clue how the
> Macintosh video architecture works.  Is it possible to change the video
> resolution and bit depth, take control of the entire video display, and
> access it directly?  Oh, this games runs in 512x384 256-color mode, by the
> way (it'll run in 640x480 with unused borders around the gameplay area).

I'll answer these one by one. Page Flipping -- no luck. There is no
standard interface for this and most video hardware (cards and built-in)
do not support it. There is a very slick way of faking two video pages
with 16 colors each -- its used in Arashi. Basicly, if you cocider the 256
color map as a 16 by 16 grid of colors. If you have two color tables, one
the same color horizontally, one with the same colors vertically --

0000000000000000
1111111111111111
2222222222222222
3333333333333333
4444444444444444
5555555555555555
6666666666666666
7777777777777777
8888888888888888
9999999999999999
AAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDD
EEEEEEEEEEEEEEEE
FFFFFFFFFFFFFFFF

0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF

This effectivly divides each pixel into two four bit "colors". You can
modify the "color" that is not being shown, then change the color table
and the image will change instantly. However, this will not work for more
than 16 color art.

Bit depth, no problem. You may however want to ask your user first. Screen
resolution, I think that there is an API for this. If not now, one will be
available soon. Hiding the menu bar is not too hard -- find sample code
and use it.

A couple of final notes -- You should handle the case of multiple screens.
Preferably, you users should be able to select a screen. If not that, make
sure that all of your graphics go to the main screen (the one with menu
bar). Also, look at QuickTime 2.1, I think it has an API for seting "whole
screen" operations.

Mick

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Sun, 05 Nov 1995 21:41:18 -0800
Organization: MacPlay

>I would like to implement some double or, preferably, triple buffering
>scheme.  This would mean I'd render the span buffer right into video memory,
>and then make that the currently visible frame by programming a video chip
>register, eliminating the overhead of transfering the bitmap to the video
>card in the CopyBits() call.  Is this possible?  I have no clue how the
>Macintosh video architecture works.  Is it possible to change the video
>resolution and bit depth, take control of the entire video display, and
>access it directly?  Oh, this games runs in 512x384 256-color mode, by the
>way (it'll run in 640x480 with unused borders around the gameplay area).

Unless you are coding the Valkyrie chip directly (which is only available
on a few Macs) then there is no such thing as page flipping.  You have one
frame buffer and that is it.  Any other buffering scheme you have to do
yourself.  However, you have a nice wide bus to video memory on the
majority of machines (especially PowerMacs) and you can get some very fast
frame rates.

Changing the video bit-depth is trivial, look at the call SetDepth().
Changing the video resolution is a little trickier and requires that you
go through the Display Manager.  Also, in Quicktime 2.1 there is a new
call BeginFullscreenMode() that lets you define a horizontal and vertical
resolution and it will try to adjust the screen size for you and creates a
new window for you to fill that area.

>The Windows version of this product will be doing things with a double-
>buffer, rendering directly to video memory using Windows 95 DirectDraw, and
>I'd love for the Mac to be able to do something similar.  Anyone have any
>suggestions or feel like giving me a quick tutorial on Mac video modes?

I suggest that you read, Inside Macintosh:  Imaging with Quickdraw.  I
think that it will clear a few things up for you.

L8R
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

+++++++++++++++++++++++++++

>From [e-mail] (Till Brychcy)
Date: 06 Nov 1995 14:58:43 GMT
Organization: Technische Universitaet Muenchen, Germany

In article <[e-mail]> [e-mail] (Chris De Salvo) writes:
[...]
   Unless you are coding the Valkyrie chip directly (which is only available
   on a few Macs) then there is no such thing as page flipping.
[...]

Where can I find information about how to do this? I couldn't find
anything about it on the developer documentation cd-rom.

--
- -----------------------------------------------------------------------
Till Brychcy                    e-mail: [e-mail]
Fakult"at f"ur Informatik
Technische Universit"at M"unchen                    Tel: [phone]
80290 Munich, Germany                               Fax: [phone]


+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosenberg)
Date: Mon, 06 Nov 1995 19:34:47 -0800
Organization: Hackers Anonymous

In article <[e-mail]>,
[e-mail] (Chris De Salvo) wrote:

>Unless you are coding the Valkyrie chip directly (which is only available
>on a few Macs) then there is no such thing as page flipping.  You have one
>frame buffer and that is it.  Any other buffering scheme you have to do
>yourself.  However, you have a nice wide bus to video memory on the
>majority of machines (especially PowerMacs) and you can get some very fast
>frame rates.

This is not entirely true. "Designing Cards and Drivers for the Macintosh
Family" documents video driver calls to find out how many pages are
available for a given mode, what the current page is, where a given page
is located, and to switch to a given page. They are supported on some
video cards. The usual case is that the user has onboard video and does
not have more than one page. The other major limitation here is that Apple
never defined video modes like 320x240, even though cards actually support
them. This is why there are makeshift calls to get around this, much as
you find in QuickTime.

The technique for page flipping with the "Valkyrie" chip is to make use of
it's video overlay capabilities to create two pages at 320x240 and flip
between them. You'll find that several PCI video cards also support video
overlays that can be used this way as well as direct support for page
flipping, so you'll see increasing support for page flipping techniques in
the future.

- -------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-  [phone]          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Mon, 06 Nov 1995 21:08:59 -0800
Organization: MacPlay

In article <[e-mail]>,
[e-mail] (Till Brychcy) wrote:

>In article <[e-mail]>
[e-mail] (Chris De Salvo) writes:
>[...]
>   Unless you are coding the Valkyrie chip directly (which is only available
>   on a few Macs) then there is no such thing as page flipping.
>[...]
>
>Where can I find information about how to do this? I couldn't find
>anything about it on the developer documentation cd-rom.

You need to talk with Apple directly about it.  The Valkyrie chip has no
official API.  It's only available on a handful of models and is meant
mainly for inbound video digitizer work, not as a page-flipping/scaling
chip.

L8R
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: Tue, 07 Nov 1995 12:46:38 +1100
Organization: Weyland Yutani

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

>In article <47c9r5$[e-mail]>, [e-mail] (Ian McLean) wrote:
>[snip]
>>I would like to implement some double or, preferably, triple buffering
>>scheme.  This would mean I'd render the span buffer right into video memory,
>>and then make that the currently visible frame by programming a video chip
>>register, eliminating the overhead of transfering the bitmap to the video
>[snip]
>
>Marathon (the original, and I assume 2) uses this, but...
>I believe that this was possible on the Quadra 630 (oslt) and is not
>possible on any other mac.  Someone PLEASE correct me if I'm wrong here.

The PCI Macs also use the 'Valkyrie' graphics chipset too I believe.
At least the 7200 does. However, accessing this hardware is another
matter altogether. I don't know of any API from Apple. There also seems
to be other limitations - you need to be in 16bit mode, and Dale Adams
(designer of the 7200 hardware) suggested that the page flipping hardware
will only run with Virtual Memory off because of "contigous memory"
reasons. And I don't know about this, but I suspect that it would only
work on a PCI Mac with a 64bit data path to memory (the stock 7200 needs
another 1Mb VRAM installed for this).

--
--
David Wareing                         [e-mail]
Belair, South Australia           [e-mail]
Macintosh Games & Multimedia Programming

+++++++++++++++++++++++++++

>From [e-mail] (Kevin McMurtrie)
Date: Mon, 06 Nov 1995 22:54:18 -0700
Organization: WEST COAST ONLINE

In article <47c9r5$[e-mail]>, [e-mail] (Ian McLean) wrote:

>Okay, now that I've flamed CodeWarrior a bit (aah, felt good; relieved some
>stress; all in all I think it's a pretty good development environment
>though) and gotten some good advice about alternative compilers, I've got a
>more technical topic: high performance blitting on the Mac.
>
>Is it possible?  Right now I'm working on a side scrolling game that, every
>frame, renders a span buffer into an off-screen bitmap, then CopyBits() to
>the screen.  I assume that CopyBits() waits for a vertical retrace before
>blitting, as I don't seem to have any tearing problems.

No, it doesn't wait.

>So, this method
>works, but it seems terribly inefficient.
>
>I would like to implement some double or, preferably, triple buffering
>scheme.  This would mean I'd render the span buffer right into video memory,
>and then make that the currently visible frame by programming a video chip
>register, eliminating the overhead of transfering the bitmap to the video
>card in the CopyBits() call.  Is this possible?  I have no clue how the
>Macintosh video architecture works.  Is it possible to change the video
>resolution and bit depth, take control of the entire video display, and
>access it directly?  Oh, this games runs in 512x384 256-color mode, by the
>way (it'll run in 640x480 with unused borders around the gameplay area).
>
>The Windows version of this product will be doing things with a double-
>buffer, rendering directly to video memory using Windows 95 DirectDraw, and
>I'd love for the Mac to be able to do something similar.  Anyone have any
>suggestions or feel like giving me a quick tutorial on Mac video modes?
>
>                                Thanks,
>                                  Ian McLean
>                                  Cyberflix, Inc.

Mac video hardware varies quite a bit, especially when you consider all of
the weird NuBus cards that existed before built-in video. I've also had
plenty of games try to set my HPV card to 4 bits and crash.  Some cheap
cards only run in 15 or 24 bits.  It is even possible that you can't set
the depth and resolution you want but CopyBits will have hardware
acceleration to make the match.  You never know.

CopyBits is very fast if you know how to make it happy.  If you can't make
it happy on strange cards it may run slowly, but at least it will still
run.  Tips are available in books and may still be periodicly posted in
programming groups.

+++++++++++++++++++++++++++

>From [e-mail] (Chris Arsenault)
Date: Tue, 07 Nov 1995 15:25:03 -0500
Organization: SandCastle Studios

In article <47c9r5$[e-mail]>, [e-mail] (Ian McLean) wrote:

> I've got a more technical topic: high performance blitting on the Mac.
>
> Is it possible?  Right now I'm working on a side scrolling game that, every
> frame, renders a span buffer into an off-screen bitmap, then CopyBits() to
> the screen.  I assume that CopyBits() waits for a vertical retrace before
> blitting, as I don't seem to have any tearing problems.  So, this method
> works, but it seems terribly inefficient.

CopyBits doesn't wait for a vertical retrace before copying. You can
install your own VBL Task and synch it up with the retrace on a specific
display.  You would definately see some tearing on the lower end systems.

> I would like to implement some double or, preferably, triple buffering
> scheme.  This would mean I'd render the span buffer right into video memory,
> and then make that the currently visible frame by programming a video chip
> register, eliminating the overhead of transfering the bitmap to the video
> card in the CopyBits() call.  Is this possible?

Currently it is not possible to reset Macintosh display memory through
redirection in a video register.  There is a hardware blitting mechanism
in some systems, notably the 630, but it's not available as a common
feature.

> Is it possible to change the video resolution and bit depth,
> take control of the entire video display, and access it directly?

Yes, but you have to remember things like the Mac being able to use
several video displays at one time.  You also want to make sure that you
maintain that Mac look and feel. :-)

In some cases you can generate a tremendous performance improvement by
directly accessing video memory.  It depends on where you need to put your
development time.  Optimizing video memory access with the various
versions of the PowerPC cache sets requires a bit more development
overhead.

My advice is to perform all offscreen work using your custom functions and
then transfer the appropriate update rects to the screen using CopyBits.
What you implement should be based on the actual performance you are
seeing across a test-lab full of machines - preferably representative of
your customer base.

> The Windows version of this product will be doing things with a double-
> buffer, rendering directly to video memory using Windows 95 DirectDraw, and
> I'd love for the Mac to be able to do something similar.  Anyone have any
> suggestions or feel like giving me a quick tutorial on Mac video modes?

Pick up a copy of "Tricks  of the Mac Game Programming Gurus" by
McCornack, Ragnemalm, Celestin, et al.  - Hayden Books  ISBN:
1-56830-183-9

It provides a fairly complete discussion about hi-performance Macintosh
game graphics.
/*------------------------------------------------------
Chris Arsenault
Senior Software Engineer
Roger Wagner Publishing, Inc.   http://www.hyperstudio.com/
Publishers of HyperStudio

Opinions and comments expressed are strictly my own.
- ----------------------------------------------------*/

+++++++++++++++++++++++++++

>From [e-mail] (Ian McLean)
Date: 8 Nov 1995 04:04:35 GMT
Organization: Internet Communications Group

In article <[e-mail]>,
Chris Arsenault <[e-mail]> wrote:
>
>My advice is to perform all offscreen work using your custom functions and
>then transfer the appropriate update rects to the screen using CopyBits.
>What you implement should be based on the actual performance you are
>seeing across a test-lab full of machines - preferably representative of
>your customer base.
>

Chris, this is excellent advice.  Thanks to the information on the
Mac video subsystems(s) provided by you, David Wareing, Chris De Salvo,
Jason Regier, Alex Rosenberg, and several others; you've really helped
me out.  If anyone is interested in this subject, let me know and I'll
email a concatination of the responses I've received.

We've recently done exactly what you suggest -- a profiler run on a
fairly representative distribution of our target platforms.  And the
basic fact is less than 10% of the CPU is ever spent blitting.  So,
development time (at least for the game engine) is best spent improving
the span buffer logic, audio codecs, intersection detection, etc.

I really can't justify the months of research and coding it would seem
to take to write a custom page flipping blitter that degrades elegantly
on older Macs.  At least one person I talked to probably has the
knowledge to do this; it would be a great project and if you went
commercial with it I could guarantee at least one customer :-)

                                        Ian McLean


---------------------------

>From [e-mail] (Gavin Kistner)
Subject: Photoshop "CLUT" into 'clut'
Date: Wed, 01 Nov 1995 01:17:14 -0500
Organization: Image Refinery Productions, Inc.

1) Writing a mac game.  Using custom graphics which start at 24-bits and
need to be dithered to a custom 8-bits.  Using photoshop to do it, and
then being unable to make a 'clut' from the info Photoshop creates.  SO...

After beating my head against walls and looking long and kinda hard for a
util to do this, I wrote one myself.  If anyone would like the source code
and/or the small app which reads in a Photoshop pseudo-clut file, creates
a real CLUT resource from it and sticks that in the resource fork of the
same file, email me.

2) So I've got this great custom clut, I've got my graphic dithered to it,
saved as a 'PICT', read in, and copied into a window.  I want to be mean
and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
NOW to *THESE* ones.  Not something close.  THESE ONES!"
How do I do this?

TIA,

- Gavin
___________________________________________________________
Gavin Kistner, aka RabYak, aka !Bob          [phone]
<-> Graphics Designer, Image Refinery Productions, Inc. <->
[e-mail]       ftp/finger to phrogz.dorm.duke.edu

+++++++++++++++++++++++++++

>From [e-mail] (PG Hurh)
Date: 1 Nov 1995 18:48:37 GMT
Organization: Leaky Faucet & Trailer Hitch

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

> 1) Writing a mac game.  Using custom graphics which start at 24-bits and
> need to be dithered to a custom 8-bits.  Using photoshop to do it, and
> then being unable to make a 'clut' from the info Photoshop creates.  SO...
>
> After beating my head against walls and looking long and kinda hard for a
> util to do this, I wrote one myself.  If anyone would like the source code
> and/or the small app which reads in a Photoshop pseudo-clut file, creates
> a real CLUT resource from it and sticks that in the resource fork of the
> same file, email me.
>
> 2) So I've got this great custom clut, I've got my graphic dithered to it,
> saved as a 'PICT', read in, and copied into a window.  I want to be mean
> and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
> NOW to *THESE* ones.  Not something close.  THESE ONES!"
> How do I do this?

Not a programmer, but I believe you can do these things with deBabelizer
Toolkit.  I've created custom palettes and attached them to pict files.
When I open the pict files in 256 mode the Mac changes the color palette on
the fly.

BTW, palette rotations and the like are described in the ToolBox Assistant
database (basically Inside Macintosh) available on Apple's developer CD's.

hope this is somewhat helpful and remotely on topic

--patrick.

+++++++++++++++++++++++++++

>From [e-mail] (Gavin Kistner)
Date: Wed, 01 Nov 1995 14:27:12 -0500
Organization: Image Refinery Productions, Inc.

After much response I've decided to put this program in all it's hackiness
online.  I'll not UL it to mac-gifts until it gets much nicer, but for now
I have it available at
ftp://phrogz.dorm.duke.edu//Nails/ULs/Guests/CLUT2clutv0.1.sit

All suggestions and comments desired and appreciated.

- Gavin
___________________________________________________________
Gavin Kistner, aka RabYak, aka !Bob          [phone]
<-> Graphics Designer, Image Refinery Productions, Inc. <->
[e-mail]       ftp/finger to phrogz.dorm.duke.edu

+++++++++++++++++++++++++++

>From [e-mail] (Timothy Hunt)
Date: 1 Nov 1995 19:21:20 GMT
Organization: Harvard University, Cambridge, Massachusetts

Gavin Kistner ([e-mail]) wrote:
: [deleted]
: 2) So I've got this great custom clut, I've got my graphic dithered to it,
: saved as a 'PICT', read in, and copied into a window.  I want to be mean
: and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
: NOW to *THESE* ones.  Not something close.  THESE ONES!"
: How do I do this?
I use SetEntries() which should be documented in IM quickdraw chapters
I'm not sure this is exactly it, but I think:
  SetEntries(-1,(*myClut)->ctSize,(*myClut)->ctTable);
should do the trick if 'myClut' is a clut handle.  I don't remember the
exact details, but there are times when you might need to fill in the
.ctTable[].value field for SetEntries to work.  I think that's only if you
start with a copy of the current device's clut.

This is not the method of changing a clut that's the most friendly to the
rest of the system and other apps, but it's simple and gives you the exact
results you asked for.  Anyone want to offer alternatives with the Palette
Manager?  Does anyone use the Palette manager?
: TIA,

: - Gavin
: ___________________________________________________________
: Gavin Kistner, aka RabYak, aka !Bob          [phone]
: <-> Graphics Designer, Image Refinery Productions, Inc. <->
: [e-mail]       ftp/finger to phrogz.dorm.duke.edu

+++++++++++++++++++++++++++

>From [e-mail] (Lee Henderson)
Date: Wed, 01 Nov 1995 14:41:20 -0600
Organization: University of Texas at Dallas

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

>1) Writing a mac game.  Using custom graphics which start at 24-bits and
>need to be dithered to a custom 8-bits.  Using photoshop to do it, and
>then being unable to make a 'clut' from the info Photoshop creates.  SO...
>
>After beating my head against walls and looking long and kinda hard for a
>util to do this, I wrote one myself.  If anyone would like the source code
>and/or the small app which reads in a Photoshop pseudo-clut file, creates
>a real CLUT resource from it and sticks that in the resource fork of the
>same file, email me.
>
>2) So I've got this great custom clut, I've got my graphic dithered to it,
>saved as a 'PICT', read in, and copied into a window.  I want to be mean
>and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
>NOW to *THESE* ones.  Not something close.  THESE ONES!"
>How do I do this?
>
I believe you can force ResEdit to do this.  I have never tried it with PICT's
 but I have done it with icl8 etc.  Try putting the clut resource in the same
resource file and then create a new PICT, choose your custom clut and load
in (possibly thru clipboard?) the PICT.  If the positions of your clut colors
are close to the colors that the clipboard uses, this may work.  Perhaps one
of those PICT to rsrc single function converter things would do it too.

Lee Henderson

+++++++++++++++++++++++++++

>From [e-mail]
Date: Wed, 01 Nov 1995 23:18:13 -0500
Organization: University of Michigan

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

> 1) Writing a mac game.  Using custom graphics which start at 24-bits and
> need to be dithered to a custom 8-bits.  Using photoshop to do it, and
> then being unable to make a 'clut' from the info Photoshop creates.  SO...
>
> After beating my head against walls and looking long and kinda hard for a
> util to do this, I wrote one myself.  If anyone would like the source code
> and/or the small app which reads in a Photoshop pseudo-clut file, creates
> a real CLUT resource from it and sticks that in the resource fork of the
> same file, email me.

I did the same thing a few months ago!
I actually have two programs:  one does clut to CLUT and the other does it
the other way 'round.

I wonder how many other people have little personal utilities like this?
I also have a little one I made a while back that just takes two PICTs and
splices them together, one on top of the other.

Here's the one that converts CLUTs to cluts:
(it may not be too elegant but it does the job)

/*** CTab to clut ***/
typedef struct OldValues
{
   unsigned char oldRed;
   unsigned char oldGreen;
   unsigned char oldBlue;
} OldValues;

typedef struct NewValues
{
   unsigned short newRed;
   unsigned short newGreen;
   unsigned short newBlue;
} NewValues;

void ToolBoxInit(void);
void DoTheThing(FSSpec theSpec);
Handle ProcessTheData(Handle data, long size);
NewValues ComputeNewValue(OldValues theOld);

void main(void)
{
   StandardFileReply reply;
   SFTypeList list;
   FSSpec theSpec;

   ToolBoxInit();
   list[0] = '8BCT';
   StandardGetFile(nil,1,list,&reply);
   if (reply.sfGood) DoTheThing(reply.sfFile);
}

void ToolBoxInit(void)
{
   InitGraf(&thePort);
   InitFonts();
   InitWindows();
   InitMenus();
   TEInit();
   InitDialogs(nil);
   InitCursor();
}

void DoTheThing(FSSpec theSpec)
{
   short fref;
   OSErr myErr;
   Handle myData, newData;
   long eof, theSize;
   short numCluts;

   if (myErr = FSpOpenDF(&theSpec,fsRdWrPerm,&fref)) {SysBeep(5);return;}
   if (myErr = GetEOF(fref,&eof)) {SysBeep(5);return;}
   theSize = eof;
   myData = NewHandle((Size)theSize);
   HLock(myData);
   if ((myErr = FSRead(fref,&eof,*myData))!=eofErr && myErr)
{SysBeep(5);return;}
   HUnlock(myData);
   if (myErr = FSClose(fref)) {SysBeep(5);return;}
   newData = ProcessTheData(myData,theSize);
   numCluts = CountResources('clut');
   AddResource(newData,'clut',128+numCluts,theSpec.name);
   DisposeHandle(myData);
}

Handle ProcessTheData(Handle data, long size)
{
   long newSize;
   Handle newHandle;
   Ptr dataPtr, bufPtr;
   short numColors, count;
   unsigned char theValue;
   unsigned short newValue;
   Boolean OneBlack = false;
   Boolean TwoBlack = false;
   OldValues theOld;
   NewValues theNew;

   numColors = size/3;
   newSize = numColors*8+8;
   newHandle = NewHandleClear((Size)newSize);
   HLock(newHandle);
   HLock(data);
   dataPtr = *data;
   bufPtr = *newHandle;

   *((short *)bufPtr) = 0;    /* this and the next one are the CtSeed field */
   bufPtr += sizeof(short);
   *((short *)bufPtr) = 0;
   bufPtr += sizeof(short);
   *((short *)bufPtr) = 0;    /* this is the CtFlags field */
   bufPtr += sizeof(short);
   *((short *)bufPtr) = numColors-1;    /* this should actually be the
real number of colors */
   bufPtr += sizeof(short);
   count = numColors;
   while(count--)
   {
      theOld = *((OldValues *)dataPtr);
      dataPtr += 3L;   /*sizeof(OldValues);*/
      if (!(theOld.oldRed||theOld.oldGreen||theOld.oldBlue))
      {
         if (OneBlack)
         {
            TwoBlack = true;
            break;
         }
         else OneBlack = true;
      }
      *((short *)bufPtr) = numColors-1-count;
      bufPtr += sizeof(short);
      theNew = ComputeNewValue(theOld);
      *((NewValues *)bufPtr) = theNew;
      bufPtr += sizeof(NewValues);
   }
   HUnlock(data);
   HUnlock(newHandle);
   if (TwoBlack)
   {
      newSize = (numColors-1-count)*8+8;
      SetHandleSize(newHandle,(Size)newSize);
      HLock(newHandle);
      bufPtr = *newHandle;
      bufPtr += (sizeof(long)+sizeof(short));
      *((unsigned short *)bufPtr) = numColors-count-2;
      HUnlock(newHandle);
   }
   return(newHandle);
}

NewValues ComputeNewValue(OldValues theOld)
{
   NewValues theNew;

   theNew.newRed = (unsigned short)(257*(unsigned short)theOld.oldRed);
   theNew.newGreen = (unsigned short)(257*(unsigned short)theOld.oldGreen);
   theNew.newBlue = (unsigned short)(257*(unsigned short)theOld.oldBlue);
   return theNew;
}

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Wed, 01 Nov 1995 22:50:35 -0800
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <478hbg$[e-mail]>, [e-mail]
(Timothy Hunt) wrote:

> I use SetEntries() which should be documented in IM quickdraw chapters
> I'm not sure this is exactly it, but I think:
>   SetEntries(-1,(*myClut)->ctSize,(*myClut)->ctTable);
> should do the trick if 'myClut' is a clut handle.  I don't remember the
> exact details, but there are times when you might need to fill in the
> .ctTable[].value field for SetEntries to work.  I think that's only if you
> start with a copy of the current device's clut.
>
> This is not the method of changing a clut that's the most friendly to the
> rest of the system and other apps, but it's simple and gives you the exact
> results you asked for.  Anyone want to offer alternatives with the Palette
> Manager?  Does anyone use the Palette manager?
> : TIA,
>
> : - Gavin

Believe it or not, I use the Palette manager, as screwed up as it is.

Here is what I do:

   CTabHandle theClut;     // the color table we will use to build the palette
   PaletteHandle gamePalette

   // Get the color table
   theClut = GetCTable( clut_GameDefaultColorTable );

   // build a palette
   mGamePalette = NewPalette( 256, theClut, pmExplicit | pmTolerant, 0 );
   SetPalette( ( WindowPtr )-1L, mGamePalette, true );

   // Dump the color table
   DisposeCTable( theClut );

The call to SetPalette makes the palette the "application palette" -- the
palette for all the windows without their own palette. The pmExplicit |
pmTolerant usage make sure that I will get the colors I want where I want
them. The disadvantage is that the application palette requires system 7
and the usage requires 32 color quickdraw.

Mick

+++++++++++++++++++++++++++

>From [e-mail] (John B. Clements)
Date: 2 Nov 1995 01:37:28 GMT
Organization: Princeton University

In article <478hbg$[e-mail]>,
Timothy Hunt <[e-mail]> wrote:
>Gavin Kistner ([e-mail]) wrote:
>: [deleted]
>: 2) So I've got this great custom clut, I've got my graphic dithered to it,
>: saved as a 'PICT', read in, and copied into a window.  I want to be mean
>: and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
>: NOW to *THESE* ones.  Not something close.  THESE ONES!"
>: How do I do this?
>
>...
>
>This is not the method of changing a clut that's the most friendly to the
>rest of the system and other apps, but it's simple and gives you the exact
>results you asked for.  Anyone want to offer alternatives with the Palette
>Manager?  Does anyone use the Palette manager?

yup, I do.  Now granted, I don't have a need for truly blazing speed, and
I haven't had access to Nifty Game Tricks books (tho' I'll probably buy
that one soon), so my techniques may not be the best available, but they
_are_ fairly kind to the rest of the system.

Note: this assumes you're using a GWorld for the offscreen picture.

If you turn that 'clut' into a 'pltt' resource (not too diff., mail me if you
want details), you can associate that with the onscreen window, and then
copy the pltt into a clut (standard routines from Palette Manager), and
_then_ (this is the tricky bit) set bit 14 of the ctFlags element in the clut
structure, then copybits will omit the color translation stage and simply use
the same pixel values, ignoring the mapping from color to color.  Since the
PICT was drawn with a clut that is identical to the pltt, there's no need for
this extra stage and copybits won't mess up your values.

Hope this has something to do w/ your question,

john


+++++++++++++++++++++++++++

>From [e-mail] (Bill the Cat)
Date: Thu, 02 Nov 1995 07:14:33 -0700
Organization: MacPascal Mailing List

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

> 1) Writing a mac game.  Using custom graphics which start at 24-bits and
> need to be dithered to a custom 8-bits.  Using photoshop to do it, and
> then being unable to make a 'clut' from the info Photoshop creates.  SO...
>
> After beating my head against walls and looking long and kinda hard for a
> util to do this, I wrote one myself.  If anyone would like the source code
> and/or the small app which reads in a Photoshop pseudo-clut file, creates
> a real CLUT resource from it and sticks that in the resource fork of the
> same file, email me.
>

Yes!  I am very much interested in this, and if you could email me the
source code and information related to it, I would be forever grateful.
=)

I am always struggling to take a 24 bit or 32 bit image and make it 8-bit
and _still_ look decent.  So far I have not been successful, so if you
could provide me any information which may help me, a hundred thanks in
advance!

_____________________________________________________________________
Bill Catambay
Pascal Programmer on Macintosh and Open VMS

              />
             //   The purpose of software engineering
     (//////[O]>=========================================-
             \\    is to manage complexity, not to create it.
              \>

____________________________________________________________________


+++++++++++++++++++++++++++

>From [e-mail] (Andrew Meggs)
Date: Fri, 3 Nov 1995 15:39:48 GMT
Organization: University of Virginia

In article <[e-mail]>,
[e-mail] wrote:

> I did the same thing a few months ago!
> I actually have two programs:  one does clut to CLUT and the other does it
> the other way 'round.
>
> I wonder how many other people have little personal utilities like this?

Probably everyone. I spent about two months writing tools (including a
CLUT-->clut tool :)) before I was able to write actual game code.

> I also have a little one I made a while back that just takes two PICTs and
> splices them together, one on top of the other.
>

I've got that one too. And one that takes two 4-bit PICTS and merges
them into one 8-bit that can fade between the two by palette animation.
And one that takes a rendering with an alpha channel and splits it into
a sprite and a mask. And everything else under the sun.

If we were nice people who weren't competing with each other in a
cutthroat segment of the software market, it would be nice if we
could share these things.

Speaking of sharing code, I should probably put a plug in here for
my 3D graphics library. Everyone go look at
  <http://darwin.clas.virginia.edu/~apm3g/deadtv/cabala/index.html>
and discover what texture-mapping speed is.

--
_________________________________________________________________________
andrew meggs                                 people who sleep really suck
[e-mail]                http://darwin.clas.virginia.edu/~apm3g/

+++++++++++++++++++++++++++

>From [e-mail] (Duncan Anker)
Date: 6 Nov 1995 01:18:36 GMT
Organization: Macquarie University

Gavin Kistner ([e-mail]) wrote:
: 1) Writing a mac game.  Using custom graphics which start at 24-bits and
: need to be dithered to a custom 8-bits.  Using photoshop to do it, and
: then being unable to make a 'clut' from the info Photoshop creates.  SO...

: After beating my head against walls and looking long and kinda hard for a
: util to do this, I wrote one myself.  If anyone would like the source code
: and/or the small app which reads in a Photoshop pseudo-clut file, creates
: a real CLUT resource from it and sticks that in the resource fork of the
: same file, email me.

Why couldn't you save your 8-bit graphics as a pict file? Doesn't Photoshop
whack the CLUT in as a resource? Just a thought.

: 2) So I've got this great custom clut, I've got my graphic dithered to it,
: saved as a 'PICT', read in, and copied into a window.  I want to be mean
: and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
: NOW to *THESE* ones.  Not something close.  THESE ONES!"
: How do I do this?

Well, you need the speech manager...

Seriously, though, maybe you should look at using the palette manager, rather
than mucking around with cluts directly. This allows you to set explicit,
or animated or whatever.

Unfortunately I have no references on hand, so I'll leave an expert to
answer your questions more specifically.

--
mailto:[e-mail]        http://hardy.ocs.mq.edu.au/~danker/

 Live pure, right wrong, and follow behind the king. Else wherefore born?

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Meggs)
Date: Mon, 6 Nov 1995 16:02:44 GMT
Organization: University of Virginia

In article <[e-mail]>, [e-mail] (PG
Hurh) wrote:
> In article <[e-mail]>,
> [e-mail] (Gavin Kistner) wrote:
>
> > 1) Writing a mac game.  Using custom graphics which start at 24-bits and
> > need to be dithered to a custom 8-bits.  Using photoshop to do it, and
> > then being unable to make a 'clut' from the info Photoshop creates.  SO...
> >
> > After beating my head against walls and looking long and kinda hard for a
> > util to do this, I wrote one myself.  If anyone would like the source code
> > and/or the small app which reads in a Photoshop pseudo-clut file, creates
> > a real CLUT resource from it and sticks that in the resource fork of the
> > same file, email me.
> >
> > 2) So I've got this great custom clut, I've got my graphic dithered to it,
> > saved as a 'PICT', read in, and copied into a window.  I want to be mean
> > and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
> > NOW to *THESE* ones.  Not something close.  THESE ONES!"
> > How do I do this?
>

You want the SetEntries call. As in,

CTabHandle my_clut = GetMyCLUTSomehow();

SetEntries( 0, 255, (**my_clut).ctTable );



> Not a programmer, but I believe you can do these things with deBabelizer
> Toolkit.  I've created custom palettes and attached them to pict files.
> When I open the pict files in 256 mode the Mac changes the color palette on
> the fly.
>

As far as I know, a PICT (hopefully) can't alter your environment just
by being drawn. Most likely, the apps are getting information that's been
encoded with the PICT or by using the Picture Utilities, and then setting
the palette themselves before drawing the PICT.

--
_________________________________________________________________________
andrew meggs                                 people who sleep really suck
[e-mail]                http://darwin.clas.virginia.edu/~apm3g/

+++++++++++++++++++++++++++

>From [e-mail] (Gavin Kistner)
Date: Tue, 07 Nov 1995 04:51:42 -0500
Organization: Image Refinery Productions, Inc.

In article <47jnpc$[e-mail]>, [e-mail]
(Duncan Anker) wrote:

>Why couldn't you save your 8-bit graphics as a pict file? Doesn't Photoshop
>whack the CLUT in as a resource? Just a thought.

Nope, it doesn't.


>: 2) So I've got this great custom clut, I've got my graphic dithered to it,
>: saved as a 'PICT', read in, and copied into a window.  I want to be mean
>: and nasty and say "Yo Mac, this is *THE* clut to use.  Change all colors
>: NOW to *THESE* ones.  Not something close.  THESE ONES!"
>: How do I do this?

Regarding everyone's advice on this question of mine:  Thanks, everyone
seems to be saying the same thing, but it doesn't seem to be working.  I
think perhaps I have one pict saved with one CLUT and am using another,
because my monitor is certainly going to funky colors, but the final
result of the drawn picture is not at all correct.  When I've tested more
I'll ask for more help on this.  Thanks again.

- Gavin
___________________________________________________________
Gavin Kistner, aka RabYak, aka !Bob          [phone]
<-> Graphics Designer, Image Refinery Productions, Inc. <->
[e-mail]       ftp/finger to phrogz.dorm.duke.edu

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Mon, 06 Nov 1995 22:33:36 -0800
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

> You want the SetEntries call. As in,
>
> CTabHandle my_clut = GetMyCLUTSomehow();
>
> SetEntries( 0, 255, (**my_clut).ctTable );

If at all possible, use the palette manager to set the color environment
-- it causes less side effects. (Believe me, I have done it both ways).
Here is the code I use to set the colors for the application:

   CTabHandle theClut;   // the color table we will use to build the palette
   // Get the color table
   theClut = GetCTable( kColorTableID );

   // build a palette
   thePalette = NewPalette( 256, theClut, pmExplicit | pmTolerant, 0 );
   SetPalette( ( WindowPtr )-1L,thePalette, true );

   // Dump the color table
   ::DisposeCTable( theClut );

This will have the same effect as the set entries calls and is much cleaner.

Enjoy --

Mick

+++++++++++++++++++++++++++

>From [e-mail] (Mark Boon)
Date: Wed, 08 Nov 1995 17:45:31 +0100
Organization: Tesuji Software B.V.

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

> In article <47jnpc$[e-mail]>, [e-mail]
> (Duncan Anker) wrote:
>
> >Why couldn't you save your 8-bit graphics as a pict file? Doesn't Photoshop
> >whack the CLUT in as a resource? Just a thought.
>
> Nope, it doesn't.
>

I've struggled a lot with this too. One solution is to use Debabelizer.
You can read in a Photoshop file and save it together with its CLUT.

Still, it won't guarantee your colors will come out right. Using
CopyDeepMask or so still often gives a dithered image for no apparent
reason. The system seems to think that a color, filtered through 100%
transparent is not the same as the original color, so it picks another
color that looks like it.

--
Mark Boon

Tesuji Software B.V.

---------------------------

>From David Reiss <[e-mail]>
Subject: Question: Best format for saving region data?
Date: 3 Nov 1995 04:03:54 GMT
Organization: http://www.astro.washington.edu

Hi.  This is a question I've been killing myself over for months and
still haven't settled on an answer.  I'm writing a board game which
has blob-shaped regions as board spaces.  I want to use them as
regions in my game, so that they support drag-and-drop, hiliting,
etc.  My question is this: how do I set up the application to store
the info on these regions (e.g. in a resource, or in the data fork)?
I've played with these options:

1. saving regions to a resource.  I'm warned that this is bad since
the format of regions may change in the future.
2. saving picts of the regions and using BitmapToRegion() to convert
these to regions at run-time.  This will be slow and a pain in the butt
to implement.
3. Do the same as (2) but use icons (can you make icons bigger than
32x32 pixels?) and use IconToRgn() (or whatever it's called) to get the
region. Disadvantage: how do you write a region into an icon resource?
4. Saving one picture of the board in a resource and a bunch of points
in resources to use as seeds for BitmapToRegion().  This is similar to
(2) but could be easier and faster.
5. Somehow create the regions (eg from lines and/or rects) at runtime.
This is a pain because I have to represent each of my blobs as a sum
of geometrical shapes.

There are probably others.  I'd love to  hear any recommendations/
experiences from all of you great game programmers.  Thanks a lot!

-David


+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 3 Nov 1995 09:59:25 GMT
Organization: (none)

David Reiss <[e-mail]> writes:

>Hi.  This is a question I've been killing myself over for months and
>still haven't settled on an answer.  I'm writing a board game which
>has blob-shaped regions as board spaces.  I want to use them as
>regions in my game, so that they support drag-and-drop, hiliting,
>etc.  My question is this: how do I set up the application to store
>the info on these regions (e.g. in a resource, or in the data fork)?
>I've played with these options:

>1. saving regions to a resource.  I'm warned that this is bad since
>the format of regions may change in the future.

This is what I do in the jigsaw game Christmas'95 (coming very soon).
Of course, I run less risk than you since I only save regions for the
"save game" feature, not for permanent data.

>2. saving picts of the regions and using BitmapToRegion() to convert
>these to regions at run-time.  This will be slow and a pain in the butt
>to implement.

Not that slow, if you use B/W PICTs and B/W offscreens, and not hard to
implement at all. A good choice.

>3. Do the same as (2) but use icons (can you make icons bigger than
>32x32 pixels?) and use IconToRgn() (or whatever it's called) to get the
>region. Disadvantage: how do you write a region into an icon resource?

Is there a standard icon-to-region call? I guess I never noticed it.
Looks like a kludge to me that will be limited. "cicn" icons can be as big
as 64x64, but other icons are limited to 32x32.

>4. Saving one picture of the board in a resource and a bunch of points
>in resources to use as seeds for BitmapToRegion().  This is similar to
>(2) but could be easier and faster.

Much harder to implement, with the seeds an all.

>5. Somehow create the regions (eg from lines and/or rects) at runtime.
>This is a pain because I have to represent each of my blobs as a sum
>of geometrical shapes.

Don't.

>There are probably others.  I'd love to  hear any recommendations/
>experiences from all of you great game programmers.  Thanks a lot!

One more is to define the shapes as polygons, which you can draw in some
drawing program which will give you plenty of freedom. You can then extract
the polygons from a picture that defines the whole layout... but it will
be more work than some of the methods above.



--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Shapiro)
Date: Mon, 06 Nov 1995 18:48:39 -0500
Organization: Rock Ridge Enterprises

In article <47c4ba$[e-mail]>, David Reiss
<[e-mail]> wrote:

> Hi.  This is a question I've been killing myself over for months and
> still haven't settled on an answer.  I'm writing a board game which
> has blob-shaped regions as board spaces.  I want to use them as
> regions in my game, so that they support drag-and-drop, hiliting,
> etc.  My question is this: how do I set up the application to store
> the info on these regions (e.g. in a resource, or in the data fork)?
> I've played with these options:

You can either:

  (1) Use regions since the format won't likely change, especially
      before Copland and then you'll probably have to update your
      code anyway.

  (2) Use polygons as the permanent storage format

Saving polygons on disk is not a bad idea because they can easily
be converted into regions at runtime using OpenRgn & DrawPoly.

If you want some sample code that converts regions into polygons,
check out the OpenDoc CD-ROM. They use polygons instead of regions
and have conversion routines as well. The reason they use polygons
is that the region structure is patented (or a trade secret anyway)
and Apple didn't want to publicly discuss the structure.

To convert regions to polygons they draw the polygon into a bitmap
and then scan the bitmap for the edges.

 -Eric Shapiro

--
Eric Shapiro
Rock Ridge Enterprises
[e-mail]

---------------------------

>From [e-mail] (Tim DeBenedictis)
Subject: Serial baud rates > 57.6KBaud?
Date: Tue, 7 Nov 1995 00:18:48 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

How do I get serial communications rates greater than 57.6KBaud?  It's
not in the FAQ, and documentation for SerReset() contains nothing higher
than 57.6 KBaud in either THINK Reference or in MPTA.  Please, no vague
answers like "Use the Communications Toolbox"!  I need a specific Toolbox
routine or a specific place to look in the Universal Headers; source code
would be ideal.

Thanks,

-Tim DeBenedictis
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Richard Cardona)
Date: Tue, 07 Nov 1995 10:17:54 -0600
Organization: TradeWave Corp.

In article <[e-mail]>, [e-mail] (Tim
DeBenedictis) wrote:

> How do I get serial communications rates greater than 57.6KBaud?  It's
> not in the FAQ, and documentation for SerReset() contains nothing higher
> than 57.6 KBaud in either THINK Reference or in MPTA.  Please, no vague
> answers like "Use the Communications Toolbox"!  I need a specific Toolbox
> routine or a specific place to look in the Universal Headers; source code
> would be ideal.
>
> Thanks,
>
> -Tim DeBenedictis
> [e-mail]

The simple answer is that there is no Apple-documented way of going over
57.6k on the serial ports.

The harder answer is that there are controls calls you can make to put the
SerialDMA driver into 230.4k mode, but not 115.2k.  According to David
Schwarz (author of SerialSpeed 230) you must write to the Serial
Controller Chip (SCC) directly to achieve 115.2k.

Guess the full potential range of the serial ports will not be available
until Copland?  I though OpenTransport would also provide some serial
support, does anyone know if a future OT will provide higher rates?

Rick

+++++++++++++++++++++++++++

>From Tom Smith <[e-mail]>
Date: Thu, 09 Nov 1995 16:47:26 -0800
Organization: Best Internet Communications

Richard Cardona wrote:
>
> In article <[e-mail]>, [e-mail] (Tim
> DeBenedictis) wrote:
>
> > How do I get serial communications rates greater than 57.6KBaud?  It's
> > not in the FAQ, and documentation for SerReset() contains nothing higher
> > than 57.6 KBaud in either THINK Reference or in MPTA.  Please, no vague
> > answers like "Use the Communications Toolbox"!  I need a specific Toolbox
> > routine or a specific place to look in the Universal Headers; source code
> > would be ideal.
> >
> > Thanks,
> >
> > -Tim DeBenedictis
> > [e-mail]
>
> The simple answer is that there is no Apple-documented way of going over
> 57.6k on the serial ports.
>
> The harder answer is that there are controls calls you can make to put the
> SerialDMA driver into 230.4k mode, but not 115.2k.  According to David
> Schwarz (author of SerialSpeed 230) you must write to the Serial
> Controller Chip (SCC) directly to achieve 115.2k.
>
> Guess the full potential range of the serial ports will not be available
> until Copland?  I though OpenTransport would also provide some serial
> support, does anyone know if a future OT will provide higher rates?
>
> Rick


Sorry Rick,  there is a way.


Excerpt from the SerialDMA 2.0 reference....


The SerialDMA driver supports two new csCodes, 115 and 230, by which its Control
routine can switch the driver to high-speed modes. These csCodes support 115.2K baud
and 230.4K baud rates. The correct time to make these calls is after a normal
SerReset call using some other (lower) baud rate. The reason for this is SerReset
performs a number of configuration tasks but assumes that the baud rate is a function
of the SCC baud rate generator. In order to achieve these two higher speeds, the baud
rate generator must be bypassed, using the standard 3.672 MHz SCC clock and one of a
very limited number of rate divisors. These csCodes effect the task of bypassing the
baud rate generator and setting the clock divisor to achieve the specified rate.


Set 115.2K Baud Rate    [control code 115]
csCode = 115
This call is designed for high-speed modems. It typically requires DMA hardware on
the receive channel to be successful. It is similar to the clock selection function
available through csCode = 16, but it instead forces the serial driver to take its
baud rate clock directly from the internal 3.672 MHz RTxC clock source with a rate
multiplier of 32. The result is to force transmit and receive baud rates of nominally
115.2K baud. Other configuration parameters are not affected.

Set 230.4K Baud Rate    [control code 230]
csCode = 230
This call is designed for high-speed modems. It typically requires DMA hardware on
the receive channel to be successful. It is similar to the clock selection function
available through csCode = 16, but it instead forces the serial driver to take its
baud rate clock directly from the internal 3.672 MHz RTxC clock source with a rate
multiplier of 16. The result is to force transmit and receive baud rates of nominally
230.4K baud. Other configuration parameters are not affected.

+++++++++++++++++++++++++++

>From [e-mail] (Richard Cardona)
Date: Fri, 10 Nov 1995 08:33:35 -0600
Organization: TradeWave Corp.

In article <[e-mail]>, [e-mail] wrote:

> Sorry Rick,  there is a way.

Hey I love being wrong when information to help us all is revealed! ;-),

> Excerpt from the SerialDMA 2.0 reference....
>
>
> The SerialDMA driver supports two new csCodes, 115 and 230, by which its
Control
> routine can switch the driver to high-speed modes. These csCodes support
115.2K baud
> and 230.4K baud rates.

Excellent! Now if every serial comm. author who fiddles with the SCC
directly can distribute the SerialDMA 2.0.x driver and use the appropriate
csCode codes we'll all be in hog heaven.

Rick

+++++++++++++++++++++++++++

>From [e-mail] (Erik Jensen)
Date: Fri, 10 Nov 1995 17:42:56 GMT
Organization: University of Windsor

In article <[e-mail]>, [e-mail] wrote:

>
>Excerpt from the SerialDMA 2.0 reference....
>
>
>The SerialDMA driver supports two new csCodes, 115 and 230, by which its
Control
>routine can switch the driver to high-speed modes. These csCodes support
115.2K baud
>and 230.4K baud rates. The correct time to make these calls is after a normal
>SerReset call using some other (lower) baud rate....

>
>Set 115.2K Baud Rate    [control code 115]
>csCode = 115
>This call is designed for high-speed modems. It typically requires DMA
hardware on
>the receive channel to be successful. It is similar to the clock
selection function
>available through csCode = 16, but it instead forces the serial driver to
take its
>baud rate clock directly from the internal 3.672 MHz RTxC clock source
with a rate
>multiplier of 32. The result is to force transmit and receive baud rates
of nominally
>115.2K baud. Other configuration parameters are not affected.
>
>Set 230.4K Baud Rate    [control code 230]
>csCode = 230
>This call is designed for high-speed modems. It typically requires DMA
hardware on
>the receive channel to be successful. It is similar to the clock
selection function
>available through csCode = 16,...

Can anyone answer a couple more questions on this-
1) Is there a gestalt for determining if the faster DMA serial driver is
available (eg. on AV Macs and PowerMacs)?

2) csCode=16 corresponds to leaving DTR enabled after closing the driver
(according to my Think Reference)- is this really the right csCode? If so,
does it matter what the csParamPtr is pointing at (is this data used at
all for this call)?

Thanks,
Erik.
__________________________________________________________________________
Erik Jensen                                   [e-mail]
Department of Physics                after Jan. 1/96 -> [e-mail]
University of Windsor

We do not live to eat and make money.  We eat and make money to be able to  enjoy life.  That is what life means and what life is for -- George Mallory
__________________________________________________________________________

---------------------------

>From [e-mail] (Chris Burns)
Subject: [Q] Macsbug ATB in PPC apps?
Date: Fri, 03 Nov 1995 13:11:58 +1300
Organization: HyperMedia Unit, Comp Sci, Auckland University

Hi all,

How do I set an ATB in a PPC native app? I've gor Macsbug 6.5.2 on a
PowerMac 8100/80 and tried (the obvious):

ATB InitGraf

but get no breaks.

What's the story?

TIA,

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x5602
Fax:      [phone]                         Async, Therefore I Am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (David A. Lyons)
Date: Thu, 9 Nov 1995 23:04:54 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> [e-mail] (Chris Burns) writes:
>How do I set an ATB in a PPC native app? I've gor Macsbug 6.5.2 on a
>PowerMac 8100/80 and tried (the obvious):
>
>ATB InitGraf
>
>but get no breaks.  What's the story?

Current MacsBug versions (6.5.2 is the latest) do not give you a great way
to break on PowerPC calls to arbitrary symbols, but there are several less-
than-great options:

--In the case of InitGraf, you can use the "atvb" (A-Trap vector break)
  dcmd, which is included in "PowerPC DCMDs" (put that file in your
  MacsBug Preferences folder, inside System Folder).

--If the symbol you want to break on in is RAM, you can put a PowerPC
  breakpoint there with BRP.  Use an Option-C for CFM to distinguish
  the PowerPC CFM symbol from the A-Trap of the same name:
      brp (Option-C)InitGraf

--BRP will also work if your symbol is in ROM, but *only* if you're
  already "in" PowerPC code (MacsBug must be showing PPC registers
  rather than 68K).

--Here's a strange-but-life-saving fallback technique for stuff in
  ROM:  Use FindSym to find the TVector that wil be used to jump to your
  symbol.  We will change the TVector to point at a few instructions in
  RAM which jump to the original location, and then put a breakpoint in RAM.

    SL PlayMem PPCJump tvector_address^
    SL tvector_address PlayMem
    BRP PlayMem

The PPCJump macro creates a 4-instruction sequence:  lis r0,0xYYYY;
ori r0,r0,0xZZZZ; mtctr r0; bctr.  If there's a way to do this without
taking 16 bytes & trashing two registers, please let me in on the secret.

If the address happens to be in the first or last 32M of the address
space (which includes the ROM on the recent PCI machines), you can
use the PPCJumpA macro, which creates a single "ba" instruction.
[For examples, try "dhp PPCJump FFC00000" and "dhp PPCJumpA FFC00000".]

--Dave (Dr MacsBug's assistant)
  Mr Tangent

--
Dave Lyons
Mr Tangent


---------------------------

End of C.S.M.P. Digest
**********************